I would also have to removed the com.sun.activation dependency from the bom, but given that some projects (= resteasy for example) depend on it, that could disable transitive overrides that you might not want to loose. Fixing resteasy's transitive dependencies isn't in scope of this PR.

The plot thickens: javax.mail uses com.sun.*.LogSupport from the sun activation jar.

[ERROR] testInlineAttachmentLegacy  Time elapsed: 0.01 s  <<< ERROR!
java.lang.NoClassDefFoundError: com/sun/activation/registries/LogSupport
	at javax.activation.MailcapCommandMap.<init>(MailcapCommandMap.java:149)
	at javax.activation.CommandMap.getDefaultCommandMap(CommandMap.java:55)
	at javax.activation.DataHandler.getCommandMap(DataHandler.java:137)
	at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:596)
	at javax.activation.DataHandler.getContent(DataHandler.java:524)
	at javax.mail.internet.MimeMessage.getContent(MimeMessage.java:1419)
	at io.quarkus.mailer.runtime.MailerImplTest.getContent(MailerImplTest.java:372)
	at io.quarkus.mailer.runtime.MailerImplTest.testInlineAttachmentLegacy(MailerImplTest.java:301)

Further research shows that activation-api doesn't contain the impl classes, but the com.sun artifact contains both impl and api classes. So given that:

• both jars contain some of the same classes (=> cannot co-exist)
• the jakarta.* jar doesn't contain the impl classes, so its not enough

the only logic conclusion is:

• Only use com.sun.* , ban jakarta.activation:jakarta-activation-api

But that doesn't seem sensible...

Feel free to close this PR, as this approach doesn't seem to be fruitful (it creates failing tests). We need to look in another way to avoid the duplicate classes of activation in quarkus.

Only use com.sun.* , ban jakarta.activation:jakarta-activation-api

Yes, that's what we're supposed to do. I don't exactly know why they decided to encapsulate the API as it's a pain but that's how it is.

@gsmet javax.activation is banned, but jakarta.activation is not yet banned:
https://github.com/quarkusio/quarkus/blob/master/build-parent/pom.xml#L293

Yes so maybe we should do that. I don't think there is a clean implementation of Jakarta Activation not including also the API.